The technology described herein relates to methods of and apparatus for displaying windows, e.g., for a graphical user interface, on a display in a unified frame buffer, and then the unified, output frame then read.
As is known in the art, many electronic devices and systems use windows for displaying information, such as a graphical user interface, game, demo, etc., to a user on a display screen (and for allowing a user to interact with an application or applications being executed).
Each individual application will typically produce a sequence of frames corresponding to their respective windows (these frames are typically generated (rendered) by a graphics processing system). The output to be displayed on the display device is then generated using the windows (frames) generated by the application or applications, usually using a so-called compositing window system, in which the windows (frames) for the application(s) are rendered appropriately into a unified frame buffer for the display in question in order to display the windows to the user. This operation of rendering the frames into the frame buffer is usually performed by a graphics processing system, under the control of a window “compositor”. The “composited” output generated by the graphics processing system that is to be displayed is usually written to a so-called “frame buffer” in memory for the display device (which may, e.g., be a screen or printer) for display. Typically a pair of frame buffers (“front” and “back” frame buffers) are provided, one to store the frame that is currently being displayed, while the next frame is written into the other.
The writing of frames to a frame buffer by a graphics processing system is a relatively expensive operation. For example, LCD displays are typically refreshed at a constant high rate typically between 60-70 Hz. Each such “refresh” involves generating and writing a new frame to the frame buffer. This involves, inter alia, lots of power hungry memory and display accesses.
It is known therefore in 2D compositing window systems to track which areas of a frame have actually changed (known as “dirty” regions) and only issue drawing commands to the graphics processing system for those changed parts of the frame. To achieve this, the existing pixel contents of the “current” frame buffer must always be copied onto the back frame buffer between frames to ensure that pixels outside of the dirty regions are preserved and correct. Copying the entire contents of the buffer can be costly, so in order to increase performance some compositors make use of graphics API (Application Programming Interface) extensions allowing them to inform the graphics processor device driver of the dirty regions that they intend to overwrite. This allows the graphics processor (GPU) to only preserve those pixels which will not be overwritten when the new frame is rendered.
However, notwithstanding this, the Applicants believe that there remains scope for improvements to such frame buffer operations in data processing systems.
Like reference numerals are used for like features in the Figures where appropriate.